-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix _polyprep
, PolynomialRatio
, for Number
args
#571
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #571 +/- ##
=======================================
Coverage 97.40% 97.40%
=======================================
Files 16 16
Lines 3193 3193
=======================================
Hits 3110 3110
Misses 83 83 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly looks good to me, but I'd like to see some justification for why
PolynomialRatio{:z,T}(b::Union{T1,Vector{<:T1}}, a::Union{T2,Vector{<:T2}}) where {T<:Number,T1<:Number,T2<:Number}
has to be some complicated.
Co-authored-by: Martin Holters <[email protected]>
Co-authored-by: Martin Holters <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM modulo minor style nits. Thanks!
Co-authored-by: Martin Holters <[email protected]>
The current implementation uses
reverse(x)
, which is a method error forNumber
arguments. ThusPolynomialRatio(::Number, ::Number)
doesn't work as currently documented.This commit also reduces runtime dispatch.edit: guess it doesn't because of all the inlining anyway2nd edit: it wasn't, but now the type instabilities have been removed by manually inlining
_polyprep